The potential benefit of M2M has resulted in a number of sector specific or vertical applications to enable machines to communicate with each other. For example one finds solutions in the healthcare sector, the energy sector, and the automotive sector. These solutions have been optimized for these vertical applications, but fail to deliver on the promise of the all-encompassing IoT, where machines and things from different vertical applications interact with each other.
To this end, a number of standards bodies (for example oneM2M) are developing service layers that define a single horizontal platform for the exchange and sharing of data among all applications, even those from different industry sectors.
From a protocol stack perspective, service layers are typically situated above the application protocol layer and provide value added services to applications. Hence service layers are often categorized as ‘middleware’ services. For example, FIG. 1 shows an example service layer 102 between an IP network stack 106 and applications 104.
An M2M service layer can provide applications and devices access to a collection of M2M-oriented capabilities (M2M services) supported by the service layer. These capabilities are made available to applications via Application Programming Interfaces (APIs). For example, an M2M service layer may maintain massive amounts of M2M data, which can be discovered, retrieved, or subscribed-to by M2M applications (provided these M2M applications have suitable access rights). Additional examples of M2M services that can be provided by the service layer include security, charging, device management, provisioning, and connectivity management.
A typical M2M deployment (shown in FIG. 2) will have a number entities/nodes that provide various levels of M2M service functionality. In non-limiting example:                M2M servers 202, which host M2M services and are operated by an M2M service provider;        M2M middle nodes (or gateways) 204, 206, 208, 210 and 212 which host M2M services        M2M devices which host M2M services 214, 216, 218, 220, 222, 224; and        “Light” M2M devices which typically host no M2M services 226, 228 and 230.        
M2M applications which can either reside on these entities or have access to these entities through a network, take advantage of the provided M2M services. As shown in the FIG. 2, these M2M services can be provided locally, for instance, M2M application1 can use the local M2M services provided by the M2M Device1 to provide data storage. In addition, the M2M services may also be provided remotely. For instance M2M application2 can use the services provided by the M2M server to make its data discoverable. Note that the M2M services deployment shown is inherently hierarchical, and this is typical of M2M service layers described in oneM2M and ETSI M2M.
oneM2M is one standard development organization (SDO) that is targeting the creation of an M2M service layer. oneM2M describes its service layer as a distributed software layer akin to an operating system. This distributed software layer is implemented in a common services layer that sits between the M2M applications and the communication hardware (HW)/software (SW) that provides data transport.
The Common Services Layer provides a set of standardized M2M services which are grouped together, by functionality, into Common Services Functions (CSFs). A number of instantiated CSFs makeup a Common Services Entity (CSE) 302. As shown in FIG. 3, these service layers (CSEs) 302 interface with:                applications (Application Entities or AEs 304 in oneM2M nomenclature) through an Mca reference point;        other service layers (CSEs), through an Mcc (or Mcc′) reference point;        the underlying networks (Network Service Entity or NSE 306 in oneM2M nomenclature) through an Mcn reference point.        
Also shown in FIG. 3 are twelve CSFs that are currently defined by oneM2M. Each of the CSFs are briefly described below:                Application and Service Layer Management CSF: provides management of AEs and CSEs. This includes capabilities to configure, troubleshoot and upgrade functions of the CSE, as well as to upgrade the AEs        Discovery CSF: searches for information about applications and services based on a filter criteria.        Registration CSF: Provides the functionality for AEs (or other remote CSEs) to register with a CSE. This allows the AEs (or the remote CSE) to use the services of the CSE.        Communication Management/Delivery Handling CSF: provides communications with other CSEs, AEs and NSEs. This CSF decides at what time and which communication connection for delivering communications and if necessary and allowed, to buffer communications request so that they can be forwarded at a later time.        Group Management CSF: provides for the handling of group related requests. Enables an M2M system to support bulk operations on multiple devices, applications, etc.        Security CSF: provides security functions for the service layer, such as access control including identification, authentication, and authorization.        Data Management and Repository CSF: provides data storage and mediation functions (collecting data for aggregation, re-formatting data, and storing data for analytics and semantic processing).        Location CSF: provides the functionality to enable AEs to obtain geographical location information.        Service Charging & Accounting CSF: provides charging functions for the service layer        Device Management CSF: provides management of device capabilities on M2M gateways and M2M devices.        Network Service Exposure, Service Execution and Triggering CSF: manages communications with the Underlying Networks for accessing network service functions        Subscription and Notification CSF: provides functionality to allow for subscribing to an event and to be notified when this event occurs.        
oneM2M is developing the service layer architecture, called Resource Oriented Architecture (ROA) shown in FIG. 4.
In ROA, the architecture is developed around resources. The CSFs operate on these resources to perform their service. A resource is a uniquely addressable element in the architecture having a representation that can be manipulated via RESTful methods such as CREATE. RETRIEVE, UPDATE, and DELETE. These resources are made addressable using Uniform Resource Identifiers (URIs). A resource may contain child resource(s) and attribute(s). A child resource is a resource that has a containment relationship with a parent resource. As a result, resources can be viewed as a hierarchical tree, stemming from a base resource. The parent resource representation contains references to its child resources(s). The lifetime of a child-resource is limited by the parent's resource lifetime. Each resource supports a set of “attributes” that store information related to the resource. A set of attributes are common to all resources, while others apply only to specific resources. The latter are referred to as “resource specific attributes”.
Within the ROA of oneM2M, there is a distinction between resources hosted in the oneM2M service layer, and entities which interact with the oneM2M system. At the service layer all interactions are initiated by entities (AEs or CSEs) through a request operation, and these requests always target a resource. The response to each of these requests is always between two entities. As a consequence, within the M2M service provider domain, each resource needs to be identified by a unique resource ID, and each entity (AE and CSE) needs to be identified by a unique entity ID. Additional, non-limiting, details are provided below:                CSE Identifier (CSE-ID): This ID identifies a CSE, and is used for all interactions from/to a CSE. Service providers assign a relative CSE-ID to each CSE, which is unique within the service provider domain. The relative CSE-ID can be made globally unique by prefixing a unique M2M Service Provider ID.        Application Entity Identifier (AE-ID): This is used to uniquely identify “an AE resident on an M2M Node, or an AE that requests to interact with an M2M Node” oneM2M-TS-0001, oneM2M Functional Architecture-V-2.6.0. In order to use the M2M services offered by the oneM2M service layer, applications must first register to a CSE. During this registration request, the application entity can either request a service provider assigned AE-ID (assigned by the IN-CSE) or a ‘locally’ assigned AE-ID (assigned by the CSE the application is registering with, also known as the registrar CSE). If assigned by the IN-CSE, the AE-ID is unique within the service provider domain. In such a case, the AE-ID starts with an ‘S’ character. In contrast, if the AE-ID is assigned by the Registrar CSE, it is only unique among all applications registered to this CSE. In such a case, the AE-ID starts with a ‘C’ character. Locally assigned AE-ID can be made unique within the service provider domain, by prefixing the CSE-ID of the Registrar CSE.        Resource ID: Most resource IDs are assigned by the CSE that is hosting the resource. The CSE may assign an unstructured ID or a structured ID. An unstructured ID is a sequence of characters that uniquely identifies the resource within the hosting CSE. In contrast, a structured ID identifies the resource within the CSE through its parent-child-relationships. It is very similar to how filenames are identified by their path, in an operating system directory structure. The resource ID can be made unique within the service provider domain, by prefixing the CSE-ID of the hosting CSE. In such a case, the ID is referred to as “Service Provider Relative Resource ID”. In particular, this ID uniquely identifies the resource within the M2M service provider domain as well as the CSE where the resource is hosted. In addition, any Resource ID can be made globally unique by prefixing a unique M2M Service Provider ID. In such a case, the ID is referred to as “Absolute Resource ID”. One important caveat about the M2M resource IDs is that they carry no routing information. So for example, FIG. 5 shows an absolute resource identifier. This resource:                    Is located within the service provider domain with M2M Service Provide ID=‘www.m2mprovider2.com’,            Is located within CSE with CSE-ID=CSE001,            Is located under resource ‘/AE1/’            Has resource name ‘cont001’                        What is important, is that the resource is not located on the server with FQDN www.m2mprovider2.com. Rather it is located on the server hosting CSE with CSE-ID CSE001. In oneM2M, the routing information of this server is maintained in a Point of Access (PoA) attribute which provides the routable location of this CSE. Note however that the PoA may include another FQDN which denotes server hosting the CSE with CSE-ID CSE001.        
FIGS. 6A-6B show examples of interactions within the oneM2M domain. In the figures, entities are shown as boxes and resources as ovals within those boxes. All service layer interactions defined in oneM2M, are through a request/response exchange between an Originator and a Receiver. The Originator may be an AE or CSE, and the Receiver is typically a CSE (see FIG. 6A). This is for interactions that involve the creation, retrieval, update, or deletion of a resource (implemented through CREATE, RETRIEVE, UPDATE, or DELETE requests). However oneM2M has defined one interaction where the Receiver is an AE (see FIG. 6B). This is the notification interaction, which is implemented through a NOTIFY request.
As shown in FIG. 6A, when the receiver is a CSE, the request originates from an entity, and may target a specific resource on the receiver CSE. Responses, in contrast, originate from a Receiver entity 604 and target an Originator entity 602. Notice that the request arrow points to a specific resource, while all other arrows begin and end at the entities. As can be seen in the figure, these arrows point to an Originator or Receiver and not to a resource. In the figure, this is denoted by the arrows terminating at the edges of the boxes and not at resources within the boxes.
As shown in FIG. 6B, the situation is slightly different for a NOTIFY request to an AE. In such a case, the request from the Originator 602 needs to target the resource that “represents” the AE. This corresponds to the <AE> child resource created on a registrar CSE, when an AE registers to this CSE (this <AE> child resource is shown in green in FIG. 6B). If the registrar CSE 606 receives a NOTIFY request targeting the <AE> resource, the CSE knows to re-target this to the registered AE.
In order to use services provided by a service layer, AEs and CSEs must first register to that service layer. This is done through specialized CREATE operations targeting the registrar CSE.
Application registration has at least the following objectives:                1. Assign an AE-ID to the application;        2. Create an <AE> resource on the registrar CSE to be used to represent/communicate with the application within the service layer.        
Additionally the application has the choice of having the AE-ID assigned by the local registrar CSE or of having the service provider involved in this assignment. If it selects the former, the AE-ID is unique with the registrar CSE, but not globally unique within the service provider domain. If the application selects the latter, then the service provider will assign the AE-ID and, in addition, the IN-CSE will announce the <AE> resource (in an <AEAnnc> resource). This announcement allows the application to be discovered by other applications or CSEs. When the AE-ID is assigned by the service provider, it is guaranteed to be globally unique within the service provider domain.
To distinguish between the two types of AE-IDs, oneM2M uses a single character prefix in the AE-ID. Namely,                The AE-ID starts with a ‘C’ character if it is assigned by the local registrar CSE.        The AE-ID starts with an ‘S’ character if it is assigned by the service provider.        
The use of the service provider assigned AE-ID, allows the service layer to know when an application is attempting a re-registration (say because it has lost connectivity or that its initial registration has expired).
A number of M2M services defined by oneM2M result in interactions with AEs. These are briefly explained in greater detail below.
Subscribe/Notify is a procedure which allows an Originator to subscribe to a resource, and to have notifications sent when certain criteria related to this resource have been met. The Originator creates a subscription to a resource, by:                1) Creating a <subscription> child resource;        2) Providing the criteria which are to be monitored (defined in eventNotificationCriteria attribute). For example an event may be triggered if the size of the resource falls below a threshold, if the resource is updated or deleted, if the resource has a new child resource, or if one of the resources child resources is deleted;        3) Providing a list of notification targets (defined in notificationURI attribute). This is where the CSE hosting the subscription resource needs to send the notifications of the events (through a NOTIFY Request/Response exchange). Each target in the list can be formatted as a oneM2M compliant Resource ID, or as an identifier compliant with a oneM2M supported protocol binding;        4) Providing other notification related policies. For example, the originator may:                    Limit the maximum number of notifications to be sent (defined in expirationCounter attribute);            Request batch notifications (defined in batchNotify attribute): and/or            Limit the rate at which notifications are sent (defined in rateLimit attribute).                        
A typical subscription example is shown in FIG. 7. A subscriber 702 makes a subscription request to the CSE hosting the subscribed-to resource (Step 1). If the Hosting CSE 704 accepts the request, it creates the <subscription> child resource (Step 2) and responds to the subscriber informing it that the subscription has been successful (Step 3). Subsequently, when there is a change in the subscribed-to resource that matches the subscriber specified criteria (Step 4), the Hosting CSE 704 will send a notification to all targets on the notification target list (Step 5 & Step 6). As the receiver in Step 6 is an AE (AE1) 708, the notification is sent to AE1s Registrar CSE 706, which is responsible for re-targeting the notification to AE1 (Step 8,9,10). Note that some details of the subscribe/notify procedure have been omitted to simplify the figure—namely the details regarding subscription verification that occurs during Step 2.
In oneM2M, requests can be of three types: Blocking, Non-Blocking Synchronous, and Non-Blocking Asynchronous. Each type defines how the Originator and intermediate CSEs deal with the request as it travels to its destination. In particular, a Non-Blocking Asynchronous request is used in cases where the Originator, or other entities that need to know about the outcome of a request, are able to receive notification messages. That is, “the CSE carrying out the requested operation may send an unsolicited message to the Originator or to other indicated entities at an arbitrary time to send the status and result of the requested operation to one or more Notification Target(s)”. The Originator issues a request to a CSE, and in this request primitive includes the list of notification targets (entities) that are to be informed of the response. A simple call flow is depicted in FIG. 8, which shows an Originator 802 attempting to UPDATE a resource on a Hosting CSE 704 and to send a response to this request to CSE1 and AE1 (Step 1). The Hosting CSE 704 stores the target information (Step 2) and responds back to the Originator 802 that the request has been accepted (Step 3). After the processing related to the resource update is complete, the Hosting CSE 704 uses a NOTIFY request to inform the targets (Step 5 & Step 6). Note that for Step 6 the target is an AE 708, so the response is first sent to the AEs registrar CSE 706, which then retargets the response to the AE 708.
The service layer may assist originators in sending a group request to a set of destination resources. These destination resources are typically of the same type, although there is a provision to allow for mixed resource types. As an example, a group can be created to allow an operation to fan out to a number of <AE> resources.
To achieve this, a <group> resource needs to be created at a group Hosting CSE. The <group> resource contains a list of resource IDs of all the members of the group (included in the memberIDs attribute). At group creation, the group Hosting CSE creates a virtual resource (<fanOutPoint>) as a child of the group resource. Subsequently, an originator may send a request operation targeting the virtual <fanOutPoint> resource, and the group Hosting CSE will, on behalf of the originator, fan out the request to the individual members of the group (those listed in the memberIDs attribute). Upon receiving the responses from each of the fanned out requests, the group Hosting CSE will aggregate the results before responding to the originator.
The service layer may assist originators in announcing resources to remote CSEs. When an originator creates an original resource on a Hosting CSE, it can request that this resource be announced to a remote CSE. The resource created in the remote CSE is referred to as an announced resource. The announced resource may have a set of attributes which are mirrors of the original resource attributes, and it may also have its own attributes—in particular a “link” attribute that points back to the original resource. Announcing a resource has two main purposes:                1) Assisting in discovery—An original resource may be discovered through its announced resource. In fact, oneM2M takes this a step further, as it allows retrieving the original resource through the remote CSE, through the “link” attribute. In this case, it is the responsibility of the remote CSE to retrieve the original resource on the Hosting CSE.        2) Mirroring attributes at remote CSEs—These attributes may be retrieved directly from the remote CSE. It is the responsibility of the original Hosting CSE to make sure that the attributes in the original Hosting CSE and the remote CSE are synchronized.        
A number of resource types can be announced—including AE, container, contentInstance, group, and remoteCSE.
Mobility management is an area of very active study in academia and industry—mainly to address the proliferation of mobile devices and the demands of the users using these devices. It enables:                Location Management: Allows a network to locate a mobile's point of attachment in order to deliver traffic to this mobile        Handoff Management: Allows a mobile to maintain its connection as it continues to change its point of attachment.        
FIG. 9 shows an example of a mobile node as it changes its point of attachment—from one LTE base station to another, than to a WCDMA base station, and finally to a WiFi access point.
Mobility management can be handled at many different layers of the protocol stack. For example, it may be handled at the network layer, through enhancements to IP and/or at the link layer, through mechanisms that rely on the radio access networks to maintain connectivity to a mobile as the mobile changes its point of attachment. Both mechanisms are described below, as well as Distributed Mobility Management (DMM) which is an approach that does not rely on use of mobility anchors.
The basic principle behind Mobile IP (MIP), is to have a mobile node (MN) preserve its IP address, but to use a Care of Address (CoA) as it moves out of its home network and into a foreign network. In each network, the mobile communicates through a router (either a Home router or a Foreign router). Three main functions are required to implement the new functionality:
Router (Agent) Discovery: Routers periodically advertise their presence, or mobile node can send an advertisement solicitation to discover these routers. If a mobile node finds that it is on a foreign network, the foreign router assigns it a CoA.
Registration: Mobile Node registers its CoA with its Home Router, which then updates its Mobility Binding Table. At same time, the Foreign Agent Router keeps a list of visiting mobile nodes—the Visitor list.
Forwarding: For mobile node outgoing traffic, this follows normal IP routing. For mobile node incoming traffic, the data goes first to the mobile node's Home Router, which acts as an anchor for the communication. The Home Router uses the Mobility Binding Table to determine that mobile node is in a foreign network. It sends the data to the CoA through a tunnel created between itself and the foreign router. The Foreign router determines that the mobile node is on its local network by cross-referencing with the Visitor list that it is maintaining, and then delivers the traffic to the mobile node.
As described below, MIP requires changes to both the mobile nodes and the routers/agents. There was a strong operator push to move all the changes to the network side. PMIPv6, based on Mobile IPv6 (MIPv6), reuses the Home Router concept but defines nodes in the network that must signal the changes in the location of a Mobile Node on its behalf. The Mobile Access Gateway (MAG) performs the mobility-related signaling on behalf of the Mobile Nodes attached to its access links. The Local Mobility Anchor (LMA), within the core network, maintains a collection of routes for each Mobile Node connected to the mobility domain. It is an anchor point for traffic destined to a MN
MNs attach to a first MAG using Router Solicitation. The MAG then notifies the LMA associating its address to the identity of MN. The LMA allocates a prefix to MN and establishes a tunnel with the MAG. The MAG forwards the prefix to MN so that MN can configure its address.
As MN moves and contacts a new MAG, the new MAG updates the LMA with the new MN location. It also advertises the same prefix to the MN—so MN has same address as it moves.
Downlink packets sent to the Mobile Node from outside, arrive to the LMA, which forwards them through the tunnel to the serving MAG. The MAG, sends the packets to the Mobile Node directly through the access link.
Uplink packets that originate from the Mobile Node are sent from the MAG, through the tunnel, to the LMA, which then forwards the packets to the destination.
In the LTE network, mobility is mobile assisted but network controlled. Mobility occurs when a mobile node changes its point of attachment from one source base station to a target base station. If the two base stations belong to the same Serving Gateway (S-GW), LTE relies on link layer mobility. The basic premise is to use the S-GW as the anchor point to forward traffic from the source base station to the target base station. This is enabled through the following basic steps:
Step 1: The mobile provides measurements to the source base station, which may trigger a handover.
Step 2: The source base station prepares the handover by transferring the mobile context to the target base station and forwarding data traffic between the source base station and target base station.
Step 3: The source base station informs the mobile to perform the handover, at which point the mobile disconnects from source base station and connects to target base station.
Once connected it confirms the handover request to the target base station.
Step 4: During transfer, the S-GW acts as a mobility anchor point moving traffic to source base station and then to target base station.
All the solutions described in Network Layer Mobility and Link layer Mobility (LTE Network), have at least the following aspects in common:                Location information in terms of mapping between session identifier and forwarding is kept is a single mobility anchor, and        Packets destined to this session identifier are forwarded by this anchor.        
It is recognized herein that there is an IETF effort to find alternatives to centralized management for the following reasons:                These anchor points become funnels—there are few in the network and they may become heavily loaded;        These anchor points become single points of failure; and/or        In many cases, networks are getting flatter—they are moving away from hierarchical deployments.        
As a result, the IETF has developed DMM, where the mobility management functions are distributed to multiple networks, thereby allowing a mobile mode to be served by a nearby function with an appropriate Forward Management Capability (FMC).